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(54) Web development and deployment using SMS and USSD 



(57) A communication system is provided that con- 
tains a protocol converting controller. The controller re- 
ceives an upstream mobile terminal (110) message from 
a mobiie terminal and converts the upstream mobile ter- 
minal message into an upstream Internet message to 
be used by an Internet server. Also, the controller re- 
ceives a downstream Internet message from the Inter- 
net server and converts the downstream Internet mes- 
sage into a downstream mobile terminal message to be 
used by the mobile terminal. The upstream and down- 
stream mobile terminal messages may have an SMS or 
USSD protocol, and the upstream and downstream In- 
ternet messages may have an HTML, HTTP, or XML 
protocol. In one implementation, the downstream Inter- 
net message is output by an Internet application stored 
on the Internet server and contains an Internet page (e. 
g. an XML page) having mobile terminal data for creat- 
ing the downstream mobile terminal message. Also, the 
XML page contains potentially responsive mobiie termi- 
nal messages and Internet addresses that respectively 



correspond to the potentially responsive mobile terminal 
messages. As a result, when the protocol converting 
controller receives an upstream mobile terminal mes- 
sage, it can determine if such message is part of an ex- 
isting session with the Internet application by determin- 
ing if the upstream mobile terminal message corre- 
sponds to any of the potentially responsive mobile ter- 
minal messages. If the upstream mobile terminal mes- 
sage corresponds to one of the messages, it is part of 
the existing session, and the upstream Internet mes- 
sage is generated based on the Internet address that is 
associated with the potentially responsive mobile termi- 
nal message corresponding to the upstream mobile ter- 
minal message. Furthermore, the Internet application 
may output cookies to the protocol converting controller 
that are used to enhance the communications between 
a mobile terminal and the Internet application. In addi- 
tion, a method performed by the communication system 
and a software program for controlling the communica- 
tion system are provided. 



< 

CD 
CD 
h- 

00 
CD 



a. 

LU 




Printed by Jouve, 75001 PARIS (PR) 



BEST AVAILABLE COPY 



BNSOOCiD: <EP ._ 1 168766AJ>J.,> 



1 EP 1 168 766 A2 2 



Description 

Field of the Invention 

[0001] The present invention relates to a communica- 
tion system thai converts a particular communication 
protocol to an Internet-based communication protocol 
and that converts the Internet-based communication 
protocol to the particular communication protocol. In one 
implementation , the system converts a communication 
protocol utilized by a mobile telephone to the Internet- 
based communication protocol, and vice versa. In addi- 
tion, the present invention relates to a method per- 
formed by the communication system and a software 
program that performs the method. 

Background of the Invention 

[0002] Recently, communication systems have been 
developed that enable users of mobile telephones to 
have limited access to various applications via the In- 
ternet. However in order for a user to access the appli- 
cations via his or her mobile telephone, the application 
must be designed in accordance with complex tele- 
phone communication protocols, such as a Short Mes- 
sage Service ("SMS") protocol or an Unstructured Sup- 
plementary Service Data ("USSD") protocol. 
[0003] The SMS protocol allows a user to send and 
receive short alphanumeric messages (typically up to 
1 60 characters) via his or her mobile telephone. Such a 
protocol was initially developed to be used in a Global 
System for Mobile communications ("GSM") systems, 
but is now also utilized In Time Division Multiple Access 
("TDMA") and Code Division Multiple Access ("CDMA") 
communication systems. The SMS protocol allows a us- 
er to connect to a communication network on a "mes- 
sage-by-message" basis. For example, if a user wishes 
to send an SMS message to the network, a connection 
between the user's mobile telephone and the network 
is established, the SMS message is sent to the network, 
and the connection is terminated. Afterwards, if a reply 
needs to be sent from the network to the user, a con- 
nection between the user's mobile telephone and the 
network is established, the SMS message is sent to the 
telephone, and the connection is terminated. 
[0004] The USSD protocol is similar to the SMS pro- 
tocol,, except that the USSD protocol allows a user to 
establish a connection to a network on a "session" basis 
instead of on a "message-by-message" basis. In partic- 
ular the USSD protocol creates a continuing connection 
between the mobile telephone and the network while 
multiple messages are exchanged between the tele- 
phone and the network, and the connection is terminat- 
ed when the session of exchanging such messages is 
completed. 

[0005] Various communications companies utilize the 
SMS and USSD protocols in their communication prod- 
ucts. Examples of the SMS and USSD protocols are the 



Short Message Peer-to-Peer ("SMPP") protocol devel- 
oped by Logical Aldiscon, the UCP protocol developed 
by CMG. the CIMD protocol developed by Nokia, and 
the NIP protocol developed by Comverse. The SMPP, 
5 UCP, CIMD, and NIP protocols are proprietary protocols 
of the respective companies identified above. 
[0006] Currently, developing Internet applications that 
can communicate with mobile telephones is complex 
and time consuming. In order to better explain such 
10 complexity, an example of a typical communication sys- 
tem that enables a mobile telephone to communicate 
with one or more applications will be described conjunc- 
tion with Fig. 1 . As shown in the figure, the system con- 
tains a mobile terminal 10, a cellular controller 30, and 
15 a plurality of application servers 40 and 50. 

[0007] The cellular controller 30 is typically an SMS 
Center (i.e. a controller that utilizes an SMS protocol) or 
a USSD Center (i.e. a controller that utilizes a USSD 
protocol) and communicates with the mobile terminal 1 0 
20 by exchanging SMS or USSD messages with the termi- 
nal 10. (SMS or USSD messages are messages that 
comply with the SMS or USSD protocol). For instance, 
the mobile terminal 1 0 sends messages to a cellular net- 
work 20 via a wireless communication link 60 (e.g., via 
25 a radio frequency channel), and the network 20 forwards 
the messages to the controller 30 via a communication 
link 70. Conversely, the cellular controller 30 sends mes- 
sages to the mobile terminal 1 0 via the network 20 and 
the communication links 60 and 70. 
30 [0008] The cellular controller 30 also exchanges SMS 
or USSD messages with the application server 40 to ac- 
cess a first application stored in the server 40 and ex- 
changes messages with the application server 50 to ac- 
cess a second application stored in the server 50. In par- 
35 ticular, the controller 30 communicates with the applica- 
tion server 40 via a dedicated communication link 80 
that connects the controller 30 and the application serv- 
er 40. Similarly, the controller 30 communicates with the 
application server 50 via the cellular network 20 and a 
40 communication link 90 that connects the server 50 with 
the network 20. The cellular controller 30 accesses the 
first and second applications by exchanging SMS or 
USSD messages with the servers 40 and 50 in accord- 
ance with the SMS or USSD protocol, and thus, the first 
45 and second applications must be designed and imple- 
mented in accordance with an SMS or USSD protocol. 
For example, the first and second applications may be 
designed and implemented in accordance with one of 
the SMPP, UCP, CIMD: or NIP protocols mentioned 
so above. 

[0009] Based on such configuration, the mobile termi- 
nal 10 can access the first application stored in the ap- 
plication server 40 by sending and receiving SMS or 
USSD messages via the cellular network 20, the cellular 
55 controller 30 : and the communication links 60. 70, and 
80, Similarly, the mobile terminal 1 0 can access the sec- 
ond application stored in the application server 50 by 
sending and receiving SMS or USSD messages via the 



2 



1 t«R7*ftA9 t v 



3 



EP1 168 766 A2 



4 



cellular network 20, the cellular controller 30, and the 
communication links 60, 70, and 90. 
[0010] As described above, the first and second ap- 
plications can be accessed by the mobile terminal 10 
because they are specifically designed and implement- 
ed in accordance with a SMS or USSD protocol. How- 
ever, designing applications based on such protocol is 
extremely difficult and time consuming. For example, 
existing Internet software programs and design tools 
currently do not enable programmers to design and im- 
plement Internet applications in accordance with the 
SMS or USSD protocol, and thus, designing such appli- 
cations to communicate with the cellular controller 30 is 
very tedious and difficult. Furthermore, in order for the 
application servers 40 and 50 to communicate with mul- 
tiple mobile terminals, they have to implement and uti- 
lize a complex session management scheme for han- 
dling data exchanged between the multiple terminals. 
Also, even though some Internet applications have been 
designed to communicate in accordance with the SMS 
or USSD protocol, most of the Internet applications are 
designed to operate only in accordance with an Internet 
protocol (e.g,, the Hyper Text Transfer Protocol ("HT- 
TP") protocol). In-other words, even after a lot of effort 
and expense are spent to develop some applications 
that can be accessed by the mobile terminal 1 0, the mo- 
bile terminal 10 still cannot access the vast majority of 
Internet applications. Moreover, the vast majority of ap- 
plications cannot be easily modified to communicate 
with the terminal 10. 

[0011] in order to attempt to overcome the above 
problems, a cellular controller has been developed that 
accesses Internet applications which have been de- 
signed in accordance with an Internet protocol and 
which have been previously processed by an operator 
of the controller. Then, the controller outputs messages 
to mobile terminals based on the processed information 
from the Internet applications. 

[001 2] Specifically, the operator of the controller uses 
a typical Internet browser to manually accesses Internet 
applications that have been designed and implemented 
in accordance with a Hyper Text Markup Language 
("HTML") protocol and receives one or more HTML pag- 
es from the applications (A HTML page is a predeter- 
mined group of data that is generated by the Internet 
application). Then, the operator utilizes a specific pro- 
gram to manually identify information within the HTML 
pages that is capable of being extracted from the HTML 
pages and select some of the extractable information. 
After the HTML pages have been processed in such 
manner the controller strips various data from the HTML 
pages to search for particular fields within the HTML 
pages and sends the data within the fields to the mobile 
terminal as an SMS message. For example, the control- 
ler may receive a web page that contains information 
about NASDAQ stocks, strip information from the web 
page to obtain data relating to the price quote of a par- 
ticular stock, and send the price quote to the mobile ter- 



minal as an SMS message. 

[0013] Although the above cellular controller can ac- 
cess Internet applications that utilize an HTML protocol, 
the controller only extracts selected information from the 

5 HTML pages that has been manually processed by the 
operator of the controller and selectively forwards the 
selected information lo the mobile terminal. As a result, 
the type and amount of information that the mobile ter- 
minal receives is somewhat limited. In addition, a sub- 

10 stantial amount of time is need to extract the selected 
information from the HTML pages, and thus, data from 
"real time" I nternet applications cannot be forwarded the 
mobile terminal in an efficient manner. 
[0014] In another attempt to overcome the above 

15 problems, a cellular controller has been developed that 
receives HTML data and outputs Wireless Markup Lan- 
guage ("WML") data to mobile terminals in accordance 
with a Wireless Application Protocol ("WAP") protocol. 
However the WAP protocol is a highly specialized com- 

20 munication protocol, and in order to operate in accord- 
ance with the WAP protocol, a mobile terminal must be 
specifically designed in accordance with the protocol 
and must have a micro-browser installed locally within 
the mobile terminal. In addition, a mobile terminal that 

25 operates in accordance with the WAP protocol can only 
receive WML data and cannot receive SMS or USSD 
messages. Since only a very small percentage of mobile 
terminals that have been specifically designed to sup- 
port the 

30 [0015] WAP protocol and receive WML data, the 
above system does not enable the vast majority of mo- 
bile terminals to access Internet applications that have 
been implemented in accordance with the HTTP proto- 
col and does not facilitate the design of Internet appli- 
es cations so that they can communicate with the vast ma- 
jority of mobile terminals. 

[0016] In yet another attempt to overcome the above 
problems, the "i-mode" protocol has been developed by 
NTT DoCoMo and employed extensively in Japan. The 

^0 j-mode protocol enables mobile terminals to communi- 
cate with Internet applications by using simplified ver- 
sions of HTML messages. However, the i-mode protocol 
still has several disadvantages. For example, since the 
protocol uses simplified versions of HTML messages, 

45 each web site that needs to communicate with a mobile 
terminal via the i-mode protocol must be modified so that 
it communicates via the simplified HTML messages. 
Thus, since the vast majority of web sites have not been 
modified to communicate via such simplified messages, 

50 the number of web sites that can be accessed by the 
mobile terminals is very limited. Also, the data rate of 
the communications between the mobile terminals and 
the Internet applications using the i-mode protocol it is 
limited to about 9.6 kbps. Although such speed may be 

55 suitable for some current communication systems, it will 
be too slow for future communication systems (e.g., 
2.5G and 3G cellular systems) that require much faster 
data rates. Additional information about the i-mode pro- 
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tocol may be found at www.nttdocomo.com. 
[0017] In accordance with one aspect of the invention, 
a communication system comprises: a protocol convert- 
ing controller that receives a first upstream mobile ter- 
minal message having a mobile terminal communica- 
tion protocol and converts the first upstream mobile ter- 
minal message into a first upstream Internel message 
having an internet protocol. 

[0018] We also provide a communication system 
comprising a protocol converting controller that receives 
a first downstream Internet message having an internet 
protocol and converts the first downstream Internet 
message into a first downstream mobile terminal mes- 
sage having a mobile terminal communication protocol, 
wherein the first downstream Internet message com- 
prises an Internet data page having: first downstream 
mobile terminal message data that is used to generate 
the first downstream mobile terminal message; first re- 
sponsive mobile terminal message data corresponding 
to a first responsive upstream mobile terminal message 
that responds to the first downstream mobile terminal 
message; and a first responsive Internet address that 
corresponds to the first responsive upstream mobile ter- 
minal message, wherein the protocol converting control- 
ler generates the first downstream mobile terminal mes- 
sage based on the first downstream mobile terminal 
message data and outputs the first downstream mobile 
terminal message. 

[0019] In another aspect of the invention, a commu- 
nication system comprises: an Internet server that re- 
ceives a first upstream Internet message having an In- 
ternet protocol, wherein the first upstream Internet mes- 
sage is based on a first upstream mobile terminal mes- 
sage having an mobile terminal communication proto- 
col, wherein the Internet server contains an Internet ap- 
plication that generates a first downstream Internet 
message based on the first upstream Internet message, 
wherein the first downstream Internet message com- 
prises an Internet data page having: first downstream 
mobile terminal message data that is used to generate 
a first downstream mobile terminal message that re- 
sponse to the first upstream mobile terminal data; first 
responsive mobile terminal message data correspond- 
ing to a first responsive upstream mobile terminal mes- 
sage that responds to the first downstream mobile ter- 
minal message: and a first responsive internet address 
that corresponds to the first responsive upstream mobile 
terminal message. 

[0O2O] In a further aspect of the invention, a commu- 
nication system comprises: a communication protocol 
controller that inputs an upstream mobile terminal mes- 
sage having a mobile terminal communication protocol, 
an upstream identification of a particular mobile terminal 
that sent the upstream mobile terminal message, and 
an upstream destination address corresponding to a 
destination of the upstream mobile terminal message; 
a first URI table that is coupled to the communication 
protocol controller, that stores first potential destination 



addresses, and that stores first potential URIs that re- 
spectively correspond to the first potential destination 
addresses; a second URI table, that is coupled to the 
communication protocol controller and that stores first 
5 potential Identifications, second potential destination 
addresses, first potential mobile terminal messages that 
respectively correspond to the first potential identifica- 
tions and the second potential destination addresses, 
and second potential URIs that respectively correspond 
10 to the first potential mobile terminal messages; and an 
Internet message generator that is coupled to the com- 
munication protocol controller and that outputs an up- 
stream Internet message having an Internet protocol, 
wherein the communication protocol controller outputs 
15 the upstream identification, the upstream destination 
address, and the upstream mobile terminal message to 
the second URI table, wherein, when the upstream iden- 
tification corresponds to a first selected identification of 
the first potential identifications, when the upstream 
20 destination address corresponds to a first selected des- 
tination address of the second potential destination ad- 
dresses, and when the upstream mobile terminal mes- 
sage corresponds to a first selected mobile terminal 
message of the first potential mobile terminal messag- 
es es f the second UlRI table outputs a first selected URI of 
the second potential URIs that corresponds to the first 
selected identification, the first selected destination ad- 
dress, and the first selected mobile terminal message, 
and the communication protocol controller outputs the 
30 first selected UlRI to the Internet message generator as 
an upstream URI, wherein, when the upstream identifi- 
cation does not correspond to any of the first potential 
identifications, the upstream destination address does 
not correspond to any of the second potential destina- 
35 tion addresses, or the upstream mobile terminal mes- 
sage does not correspond to any of the first potential 
mobile terminal messages, the second IJRJ table out- 
puts a no match signal to the communication protocol 
controller, wherein, when the communication protocol 
40 controller receives the no match signal, the communi- 
cation protocol controller outputs the upstream destina- 
tion address to the first URI table, wherein, when the 
first URI table inputs the upstream destination address, 
the first URI table identifies a second selected destina- 
45 tion address of the first potential destination addresses 
that corresponds to the upstream destination address, 
and outputs a second selected URI of the first potential 
URIs that corresponds to the second selected destina- 
tion address, wherein, when the first UlRI table outputs 
50 the second selected URI, the communication protocol 
controller outputs the second selected URI to the Inter- 
net message generator as the upstream URI, and 
wherein the Internet message generator outputs the up- 
stream Internet message based on the upstream URI. 
55 [0021] We also provide a communication method 
comprising: (a) receiving a firsi upstream mobile termi- 
nal message having a mobile terminal communication 
protocol; and (b) converting the first upstream mobile 
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terminal message into a first upstream Internet mes- 
sage having an Internet protocol. 
[0022] In a further aspect of the invention, a commu- 
nication method comprises: (a) receiving a first up- 
stream Internet message having an Internet protocol, 5 
wherein the first upstream Internet message is based 
on a first upstream mobile terminal message having an 
mobile terminal communication protocol, (b) generating 
a first downstream Internet message based on the first 
upstream Internet message, wherein the first down- 10 
stream Internet message comprises an Internet data 
page having, first downstream mobile terminal message 
data that is used to generate a first downstream mobile 
terminal message that response to the first upstream 
mobile terminal data; first responsive mobile terminal f5 
message data corresponding to a first responsive up- 
stream mobile terminal message that responds to the 
first downstream mobile terminal message; and a first 
responsive Internet address that corresponds to the first 
responsive upstream mobile terminal message. 20 
[0023] In accordance with a further aspect, a software 
program contained in a computer readable medium is 
provided. The software program instructs a communi- 
cation system to perform a routine, comprising: (a) re- 
ceiving a first upstream mobile terminal message having 25 
a mobile terminal communication protocol; and (b) con- 
verting the first upstream mobile terminal message into 
a first upstream Internet message having an Internet 
protocol. 

[0024] A software program contained in a computer 30 
readable medium is also provided. The software pro- 
gram instructs a communication system to perform a 
routine, comprising: (a) receiving a first downstream In- 
ternet message having an Internet protocol; (b) convert- 
ing the first downstream Internet message into a first 35 
downstream mobile terminal message having a mobile 
terminal communication protocol, wherein the first 
downstream Internet message comprises an Internet 
data page having: first downstream mobile terminal 
message data that is used to generate the first down- *o 
stream mobile terminal message; first responsive mo- 
bile terminal message data corresponding to a first re- 
sponsive upstream mobile terminal message that re- 
sponds to the first downstream mobile terminal mes- 
sage; and a first responsive Internet address that corre- <*$ 
sponds to the first responsive upstream mobile terminal 
message, wherein the first downstream mobile terminal 
message is generated based on the first downstream 
mobile terminal message data; and (c) outpuiting the 
first downstream mobile terminal message. 50 
[0025] The software program may instruct a commu- 
nication system to perform a routine, comprising: (a) re- 
ceiving a first upstream Internet message having an In- 
ternet protocol, wherein the first upstream Internet mes- 
sage is based on a first upstream mobile terminal mes- 55 
sage having an mobile terminal communication proto- 
col, (b) generating a first downstream Internet message 
based on the first upstream internet message, wherein 



8 

the first downstream Internet message comprises an In- 
ternet daia page having: first downstream mobile termi- 
nal message data that is used to generate a first down- 
stream mobile terminal message that response to the 
first upstream mobile terminal data; first responsive mo- 
bile terminal message data corresponding to a first re- 
sponsive upstream mobile terminal message that re- 
sponds to the first downstream mobile terminal mes- 
sage; and a first responsive Internet address that corre- 
sponds to the first responsive upstream mobile terminal 
message. 

[0026] The present invention provides a communica- 
tion system, method, and software routine that over- 
come the above and other disadvantages of convention- 
al communication systems. 

[0027] The present invention provides a communica- 
tion system, method, and software routine that converts 
a protocol utilized by mobile terminals into an Internet 
protocol and vice versa and that can transfer data at high 
rates (e.g., in excess of 100 kbps). 
[0028] The present invention can convert an SMS or 
USSD protocol utilized by mobile terminals into an in- 
ternet protocol and vice versa. Thus, the invention ena- 
bles a mobile terminal that operates in accordance with 
an SMS or USSD protocol to access Internet applica- 
tions and to facilitate the design of Internet applications 
so that they can communicate with the mobile terminal. 
[0029] An advantage of the present invention is that 
it enables a mobile terminal that operates in accordance 
with a mobile terminal protocol to access Internet appli- 
cations and to facilitate the design of Internet applica- 
tions so that they can communicate with the mobile ter- 
minal. 

[0030] The present invention can provide a commu- 
nication system, method, and software routine that 
stores links to other web pages that may be accessed 
by a mobile terminal based on the web page that has 
been previously accessed by the mobile terminal, and/ 
or that downloads and stores other web pages that may 
be accessed by a mobile terminal based on the web 
page that has been previously accessed by the mobile 
terminal. 

[0031] The present invention can also store cookies 
based on the communications between a mobile termi- 
nal and an Internet application to enhance the session 
management techniques used by the application. 

Brief Description of the Drawings 

[0032] The above and other objects and advantages 
of the present invention will become more apparent by 
describing in detail preferred embodiments thereof with 
reference to the attached drawings in which: 

Fig. t shows a conventional communication system 
in which a mobile terminal can communicate with 
an application server; 

Fig. 2 shows a communication system in accord- 
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ance with an illustrative embodiment of the present 
invention; 

Fig. 3 shows a illustrative example of the detailed 
structure of the cellular-to-web converter shown in 
Fig. 2; 

Fig. 4 shows an illustrative example of data that is 
stored in the SMS-code-to-URi table shown in Fig. 
3; 

Fig. 5 shows an illustrative example of data that is 
stored in the session resolution table shown in Fig. 
3; 

Fig. 6 shows an illustrative example of data that is 
stored in the cookies table shown in Fig. 3; 
Fig. 7 shows an illustrative example of the process 
flow of data communications transferred over the 
communication system shown in Fig. 2: and 
Fig. 8 shows an illustrative detailed example of data 
that is stored in the session resolution table shown 
in Fig. 3. 

Detailed Description of the Preferred Embodiments 

[0033] The following description of the preferred em- 
bodiments discloses specific configurations, compo- 
nents, and process steps. However, the preferred em- 
bodiments are merely examples of the present inven- 
tion, and thus, the specific features described below are 
merely used to more easily describe such embodiments 
and to provide an overall understanding of the present 
invention. Accordingly, one skilled in the art will readily 
recognize that the present invention is not limited to the 
specific embodiments described below. Furthermore, 
the descriptions of various configurations, components, 
and steps of the present invention thai would have been 
known to one skilled in the art are omitted for the sake 
of clarity and brevity. 

[0034] The present invention relates to a communica- 
ton system, method and software program that can 
quickly and easily convert data generated by an Internet 
application implemented in accordance with an Internet 
protocol into data that can be read by a mobile terminal 
that operates in accordance with a standard mobile ter- 
minal protocol, in addition, the software program may 
be stored via a read only memory ("ROM"), a random 
access memory ("RAM"), a floppy disk, a hard disk, an 
optical disk, a carrier wave (e.g. a carrier wave transmit- 
ted via the internet, a vertical blanking interval of a tel- 
evision signal, etc.) , or any other computer readable me- 
dium. 

[0035] In an illustrative, non-limiting embodiment of 
the present invention, a communication system has 
been developed that enables mobile terminals (e.g., 
mobile telephones), which send and receive data in ac- 
cordance with a standard mobile terminal protocol (e.g., 
the SMS or USSD protocol), to communicate with an 
internet application that is implemented in accordance 
with an Internet protocol (e.g., the HTTP, Extensible 
Markup Language ("XML"), or HTML protocol). An ex- 



ample of the illustrative embodiment is shown in Fig. 2. 
[0036] As shown in the figure, the system contains a 
mobile terminal H0,a cellular controller 1 30, a Celtular- 
to-Web ("CTW") converter 140, and a plurality of appli- 
5 cation servers 1 50 and 170. The cellular controller 130 
may be an SMS Center or a USSD Center and may com- 
municate with the mobile terminal 110 by exchanging 
SMS or USSD messages with the terminal 110. In such 
a scenario, the mobile terminal 1 1 0 sends SMS or USSD 
10 messages to a cellular network 1 20 via a wireless com- 
munication Jink 180, and the network 120 forwards the 
messages to the controller 1 30 via a communication link 
190. In addition, the cellular controller 130 sends mes- 
sages to the mobile terminal 110 via the network 120 
15 and the communication links 180 and 190 

[0037] The cellular controller 1 30 may also supply the 
SMS or USSD messages to the CTW converter 140 via 
the communication link 200. The CTW converter 140 
may be a Short Message ( M SM H )-to-Web converter that 
20 translates the SMS or USSD messages from the cellular 
controller 130 into messages that comply with an Inter- 
net protocol (e.g., an HTTP, XML, or HTML protocol). 
For example, the CTW converter 140 may convert SMS 
or USSD messages into HTTP requests 210 and 220. 
25 [0038] The CTW converter 140 communicates with 
the application server 150 by outputting an HTTP re- 
quest 21 0 to the application server 150, and the request 
210 accesses a web server 155 within the application 
server 150. When the web server 155 is accessed, a 
30 back-end web server is activated, generates a HTTP re- 
sponse 215 to the HTTP request 210, and supplies the 
response 215 to the converter 140. Various back-end 
web server technologies (e.g., Common Gateway Inter- 
face ("CGI") technoiogy ! Active Server Pages ("ASP") 
35 technology, Java Server Pages ("JSP") technology, etc.) 
may be used within the back-end server to generate the 
response 215. In addition, the HTTP response 21 5 may 
include an XML page. 

[0039] Also, the CTW converter 140 communicates 
40 with the application server 1 70 by outputting an HTTP 
request 220 to the Internet 160, and the Internet outputs 
a corresponding HTTP request 230 to the application 
server 1 70 , The application server 1 70 and a web server 
175 within the server 1 70 process the request 230 in a 
45 manner that is similar to the manner in which the servers 
150 and 155 process the request 210. Accordingly, the 
application server 1 70 generates a corresponding HT- 
TP response 235 {that may include an XML page) and 
supplies it to the internet 160. Then f the internet 160 
so supplies a corresponding HTTP response 225 to the 
CTW converter 140. 

[0040] After the CTW converter 1 40 receives the HT- 
TP response 215 and/or the HTTP response 225. it con- 
verts the response 21 5 and/or the response 225 into one 
55 or more SMS or USSD messages. Then, the SMS or 
USSD messages are supplied to the cellular controller 
130 via the communication link 200, and controller 130 
outputs the messages to the mobile terminal 11 0 via the 
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cellular network 120 and the communication links 180 
and 190. 

[0041] in the embodiment shown in Fig. 2, the cellular 
controller 1 30 and the CTW converter 1 40 are depicted 
as being two separate controllers that execute two dff- 5 
ferent software programs. However, the present embod- 
iment is clearly nol limited to such a configuration. For 
example, the converter 140 can be incorporated within 
the cellular controller 130 such that a single controller 
executes a single software progrem that performs the 10 
functions of both the cellular controller 1 30 and the CTW 
converter 140. 

[0042] A detailed example of the structure of the CTW 
converter 140 is illustrated in Fig. 3. Furthermore, the 
CTW converter 140 may be implemented via software, 
hardware, or a combination of hardware and software. 
Also, in the illustrative example shown in the figure, the 
controller 130 (Fig. 2) corresponds to an SMS center 
130 (Fig. 3). and the CTW converter 140 is configured 
to interact with the SMS center 130. However, the CTW 
converter 140 may have a different configuration if it in- 
teracts with a different type of controller 1 30 and/or other 
devices. 

[0043] In any event, in the non-limiting example 
shown in Fig. 3, the CTW converter 140 comprises an 
SMS-To-Uniform Resource Identifier ("SMS/URI") table 
1401, a cookies table 1402, a SMS center connector 
1403, an HTTP request manager 1404, and a session 
resolution table 1405, The SMS center connector 1403 
inputs the SMS messages from the SMS center 1 30 and 
outputs SMS messages to the SMS center 130. 
[0044] The SMS/URI table 1401 stores a Uniform Re- 
source identifier ("URl") that corresponds to each SMS 
message that may be received from the SMS center 1 30 
when a user initially desires to access an application 
stored in the application server 150. In one implemen- 
tation, each SMS message contains or is associated 
with an SMS destination address that identifies the ap- 
plication (and/or application server) to which the SMS 
message is sent. In a further implementation, an SMS 
destination address of an Internet application is the ad- 
dress to which all of the SMS messages (that are ad- 
dressed to such application) are sent. For example, the 
destination address may be a destination telephone 
number of the application server (or the cellular control- 
ler) to which the SMS message is sent. In a GSM sys- 
tem, the destination address may correspond to an Mo- 
bile Station Integrated Services Digital Network ("MSIS- 
DN") number, and in a TDM A/CDMA system the desti- 
nation address may correspond to a Mobile Identifica- 
tion Number ("MIN"). 

[0045] The table 1401 stores alt of the possible SMS 
destination addresses and the URts that respectively re- 
late to the SMS destination addresses such that each 
URl is associated with a corresponding SMS destination 
address. In other words, the table 1 401 may be consid- 
ered to be a "took up table" that associates each SMS 
destination address with a URI : and an illustrative env 



bodiment of the SMS/URI table 1401 is shown in Fig. 4. 
In one implementation of the embodiment, the various 
URIs that are associated with the SMS destination ad- 
dresses are determined by the designer of the CTW 
converter 140. in another embodiment, the SMS/URI ta- 
ble 1 401 is a "look up table" that stores ail of the possible 
SMS messages and URIs corresponding to the SMS 
messages and that respectively associates all of the 
possible SMS messages with the URIs. 
[0046] The session resolution table 1405 stores data 
relating to each userthat is currently using the CTW con- 
verter 140 to communicate with one of the application 
servers connected to the converter 140 (e.g., the appli- 
cation server 1 50). In particular, when a user is currently 
interacting with an application stored on the server 150 
(i.e. is "in session" with the application), the user outputs 
a command to the CTW converter 1 40 via the SMS cent- 
er 1 30, Then, as described in more detail below, the con- 
verter 140 outputs an HTTP request to the server 150. 
and the application causes the server 150 to output an 
appropriate HTTP response to CTW converter 140 
based on the HTTP request. The HTTP response iden- 
tifies a finite number of possible responsive SMS mes- 
sages that the user may create in response to the HTTP 
response. The session resolution table 1405 stores the 
possible response SMS messages and the URIs re- 
spectively relating to each of the possible responsive 
SMS messages for each user that is currently in session 
with an application stored on the application server 1 50. 
In addition, if the SMS destination address of each SMS 
message is not actually contained in the SMS message, 
the session resolution table 1405 may also store the 
SMS destination addresses corresponding to the pos- 
sible responsive SMS messages. 
[0047] In one implementation of the embodiment, the 
session resolution table 1405 is a "took up table" that 
(1) Identifies the possible responsive SMS messages 
that may be generated by each user in session with an 
Internet application, (2) identifies the SMS destination 
addresses that respectively correspond to the possible 
responsive SMS messages, and (2) identifies the URIs 
that respectively correspond to the possible responsive 
SMS messages. An example of such a "look up table" 
is shown in Fig. 5. 

[0048] In addition, as shown in Fig. 3, the SMS/URI 
table 1401 and the session resolution table 1405 are il- 
lustrated as two separate tables. However, such tables 
1401 and 1405 may be combined into a single table. 
Also, the SMS/URI table 1401 and session resolution 
table 1 405 may be located within the same device (e.g. 
a Random Access memory "RAM") or within separate 
memory devices. 

[0049] The cookies table 1402 stores the HTTP cook- 
ies received from the application server 1 50 for each of 
the users that are currently in session with the applica- 
tion stored on the server 150 and the URIs that respec- 
tively correspond to the cookies. In one implementation 
the table 1402 is a "look up table" that identifies each 
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user that is currently in session with the application and 
lists all of the cookies corresponding to the URls that 
need to be called during each user's session. An exam- 
ple of the "look up table" is shown in Fig. 6. 
[0050] The HTTP request manager 1 404 sends HTTP 
requests to the application server 150 based on the out- 
put from the SMS center connector 1 403 and other data. 
Also, the HTTP request manager 1404 receives HTTP 
responses from the server 1 50 and processes such re- 
sponses. 

[0051] A more detailed example of the operation of 
the CTW converter 140 shown in Fig. 3 is described be- 
low. First, the SMS center connector 1403 waits until an 
SMS message is output from the SMS center 130. Upon 
receiving the message, the connector 1403 determines 
the identification ("ID") of the mobile terminal that sent 
the SMS message and determines the SMS destination 
address of the SMS message. In one implementation, 
the mobile terminal is a mobile telephone, and the ID 
corresponds to the telephone number of the telephone. 
Also, the ID may be included in the header or some other 
portion of the SMS message, or it may be transmitted 
as a separate message concurrently with the SMS mes- 
sage. Also, as described above, the SMS destination 
address may be included in the header or some other 
portion of the SMS message ! or it may be transmitted 
as a separate message concurrently with the SMS mes- 
sage. 

[0052] Afterwards, the SMS center connector 1403 
supplies the SMS message, the ID, and the SMS desti- 
nation address to the session resolution table 1405 to 
determine if the mobile terminal and the SMS message 
are currently involved in a session with an application 
stored on the server 1 50. For example, if the ID, the SMS 
message, and the SMS destination address received by 
the SMS center connector 1 403 are not contained in the 
table 1405, the mobile terminal and the SMS message 
are not currently involved in a session with the applica- 
tion stored in the server 1 50. In such a case, the session 
resolution table 1405 outputs a M No Session" signal to 
the SMS center connector 1 403 to inform the connector 
1 403 that the mobile terminal and the SMS message are 
not currently involved in a session. 
[0053] When the SMS center connector 1403 re- 
ceives the "No Session" signal, the connector 1403 out- 
puts the SMS destination address to the SMS/URI table 
1 401 to determine the URi that corresponds to the SMS 
message. For example, if the SMS destination address 
equals SMS DEST1, the connector 1403 outputs the 
SMS destination address SMS DEST1 to the table 
1401 . As shown in Fig. 4, the URI1 corresponds to the 
address SMS DEST1 , and thus, the table 1401 outputs 
the URU to the connector 1403 in response to the ad- 
dress SMS DEST1. 

[0054] When the SMS center connector 1403 re- 
ceives the appropriate URI from the SMS/URI table 
1401 , it sends the URI, the SMS message, and the ID 
to the HTTP request manager 1404. When the HTTP 



request manager 1404 receives such information, it 
sends the ID and the URI to the cookies table 1402 to 
determine if cookies have been previously stored in the 
cookies table 1402 that correspond to the ID and the 
5 URI (i.e. that correspond to the mobile terminal currently 
accessing the application in the server 150). For exam- 
ple, if the ID equals ID1 and the URI equals URI2, the 
cookies table 1402 indicates that the cookie Cookie2 
corresponds to the ID and URI. (Fig. 6). In such case, 
10 the cookie Cookie2 is supplied to the HTTP request 
manager 1404 in response to the ID. On the other hand, 
if no cookies correspond to the ID and URI, the table 
1 402 does not output any cookies to the manager 1 404. 
[0055] After determining whether or not any cookies 
15 correspond to the ID and URI, the HTTP request man- 
ager 1404 generates an HTTP request and outputs it to 
the application server 150. The HTTP request compris- 
es the URI, SMS message, and ID received from the 
SMS center connector 1403 and any cookies received 
20 from the cookies table 1402. After the HTTP request is 
sent to the server 150, the HTTP request manager 1404 
waits to receive a corresponding HTTP response from 
the application server 150 in reply to the request. 
[0056] When the application server 150 receives the 
25 HTTP request, the application generates an HTTP re- 
sponse based on the request. In one embodiment, the 
HTTP response comprises XML data and any relevant 
cookies. Then, the HTTP response is output to the HT- 
TP request manager 1404. 
30 [0057] Upon receiving the HTTP response, the HTTP 
request manager 1404 extract the new cookies (if any) 
and the new URls corresponding to the new cookies (if 
any) from the request and sends the cookies and URls 
to the cookies table 1402. Also, if any cookies are re- 
35 ceived, the HTTP request manager 1404 sends the ID 
of the mobile terminal to which the HTTP response is 
addressed to the table 1402. Then, the cookies table 
1402 stores the ID, cookies, and URls in the manner 
shown in Fig. 6. In addition, the manager 1 404 examines 
40 the OPTION tags contained in the XML data and ex- 
tracts the ONPICK attributes and the ONKEY attributes 
from the OPTION tags. The ONKEY attributes corre- 
spond to the various possible SMS messages that the 
user may create in response to the HTTP response, and 
45 the ONPICK attributes correspond to the URls respec- 
tively relating to the possible SMS messages. Once the 
possible SMS messages and corresponding URls are 
identified, they are stored in the session resolution table 
1405, along with the ID of the mobile terminal that 
so caused the HTTP response to be generated and the 
SMS destination address of the application (and/or ap- 
plication server 150). The ID. SMS messages. SMS 
destination address, and URls may be stored in the ta- 
ble 1405 in the formal shown in Fig. 5 and may replace 
55 any previous SMS messages and URls that were pre- 
viously stored with respect to the ID of the mobile termi- 
nal and the SMS destination address of the application 
(and/or server 150). 
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[0058] After the relevant data is stored in the session 
resolution table 1405, the HTTP request manager 1404 
examines the XML data in the HTTP response and ex- 
tracts the SMS message that should be forwarded to the 
mobile terminal from the XML data. As described in 
more detail below, the SMS message is part of the actual 
XML data and is identified by Ihe XML dala with an ap- 
propriate tag. As a result, extracting the SMS message 
is extremely easy and does not require a substantial 
amount of time. After extracting the SMS message ; the 
HTTP request manager 1 404 outputs the SMS message 
and the ID of the mobile terminal that is intended to re- 
ceive the SMS message to the SMS center connector 
1403, and the connector 1403 forwards the SMS mes- 
sage and ID to the SMS center 130. Upon receiving the 
SMS message and ID, the SMS center 130 forwards the 
SMS message to the mobile terminal identified by the 
ID. 

[0059] In the example above, when the SMS center 
connector 1403 initially receives the SMS message, 
SMS destination address, and the ID from the SMS 
center 130, the SMS message and mobile terminal are 
not currently involved in a session with the application 
stored on the server 150. Therefore, when the SMS 
center connector 1403 outputs the SMS message, SMS 
destination address, and ID to the session resolution ta- 
ble 1 405, the table 1 405 responds by outputting the "No 
Session" signal to the connector 1403. However, if the 
mobile terminal and the SMS message are currently in 
session with an application, the session resolution table 
1405 outputs an URI to be used during the session. 
[0060] For example, if the SMS center connector 
1403 receives an ID that equals ID2, receives an SMS 
message thai equals SMS1 1 , and receives an SMS des- 
tination address that equals SMS DEST2.. the connector 
1403 outputs the ID2. the message SMS11 . and the ad- 
dress SMS DEST2to the session resolution table 1405. 
As shown in Fig. 5, the ID2, the message SMS11 , and 
the address SMS DEST2 are contained in the table 
1405, and thus, the mobile terminal and the SMS mes- 
sage are currently involved in a session with the appli- 
cation. Also, the table 1405 indicates that the URI cor- 
responding to the message SMS 11 and address SMS 
DEST2 equals URI11. As a result, the table 1405 out- 
puts the URI1 1 to the SMS center connector 1 403. After 
the connector 1403 receives the URH1, it outputs the 
URI11 f the SMS message, and the ID to the HTTP re- 
quest manager 1404, and the remaining portions of the 
CTW converter 140 operate in the manner described 
above. On the other hand, as mentioned above, if the 
ID2 and the address SMS DEST2 are not contained in 
the table 1405, the table outputs a "No Session" signal 
to the connector 1403. 

[0061 ] A specific example of the communication be- 
tween the mobile terminal 1 1 0 and the application server 
150 will be described below in conjunction with Figs. 2. 
3, and 7. As shown in Fig. 7, which illustrates the flow 
of information among the various devices shown in Fig. 



2, a user can initiate a session with an application stored 
on the application server 150 by inputting a particular 
command or destination address via the mobile terminal 
110. For example, the user may input a MAIN MENU 

5 command via the mobile terminal 1 1 0 by pressing a par- 
ticular button on the mobile terminal 1 1 0 or by pressing 
certain keys in a predetermined order. Additionally or al- 
ternatively, the user may input the MAIN MENU com- 
mand by speaking a certain word or words into the mo- 

to bile terminal 110 and having the mobile terminal 110 rec- 
ognize the command via voice recognition techniques. 
[0062] Once the user inputs the particular command 
or destination address, the mobile terminal 110 outputs 
an initial SMS message and the ID of the mobile terminal 

is 110 to the SMS center 130 (step S300). Also, in the 
present example, the ID equals "111111", which may or 
may not correspond to the telephone number of the mo- 
bile terminal. When the SMS center 130 receives the 
initial SMS message and the ID, it determines the SMS 

20 destination address (e.g., "999999") of the application 
and forwards the SMS message, SMS destination ad- 
dress, and ID to the CTW converter 140 (step S310). 
Alternatively, the mobile terminal 110 may output the 
SMS destination address to the SMS center 130, and 

25 the center 1 30 does not determined the SMS destination 
address. 

[0063] The CTW converter 140 receives the initial 
SMS message, SMS destination address, and ID and 
converts the SMS message into an initial HTTP request 

20 (step S320). Specifically, the converter 140 inputs the 
initial SMS message, SMS destination address, and ID 
via the SMS center connector 1403, and the connector 
1403 outputs the SMS message, SMS destination ad- 
dress, and the ID to the session resolution table 1405. 

35 Since the mobile terminal 110 (having an ID equaling 
"11 11 11") is not currently involved in a session with an 
application in the application server 150 (or with an ap- 
plication in any other server), the session resolution ta- 
ble 1 405 outputs a "No Session" signal to the SMS cent- 

w er converter 1403 As a result, the SMS center converter 

1 403 outputs the SMS destination address (or the initial 
SMS message) to the SMS/URI table 1401, and the ta- 
ble 1401 outputs a corresponding URI to the SMS center 
connector 1403 based on the SMS destination address 

^5 (or the initial SMS message). For example, the SMS/ 
URI table 1 401 may output the following URI to the con- 
nector 1403: 

http://www.mobileinfo.com/default.asp 
[0064] Upon receiving the URI, the SMS center con- 

50 nector 1 403 outputs the URI, initial SMS message, and 
ID to the HTTP request manager 1 404. The manager 

1404 then outputs the ID and URI to the cookies table 
1 402 to determine if any cookies are needed for the mo- 
bile terminal 1 1 0 having the ID equaling "111111" and for 

55 the URI equaling "http://www.mobiieinfo.com/default. 
asp" to access the application in the server 150. If any 
cookies are required, the cookies table 1 402 outputs the 
cookies to the HTTP request manager 1404. Then, the 
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HTTP request manager 1404 forms an initial HTTP re- 
quest comprising the URI r the initial SMS message, the 
ID of the mobile terminal 110, and any necessary cook- 
ies. An example of the initial HTTP request may be as 
follows: 

http-y/www.mobileinfo.com/defaulL.asp?mo- 
bilenum=l11111&text= 

In the above example, the "URI portion" of the HTTP 
request equals "http://www.mobileinfo.com/default. 
asp", the "ID portion" of the HTTP request equals "mo- 
bilenum = 111111", and the "SMS message portion" of 
the HTTP request equals "text =". As noted in the above 
example, the "SMS message portion" of the HTTP re- 
quest does not contain any SMS message text. 
[0065] After the HTTP request is formed, the HTTP 
request manager 1404 supplies il to the application 
server 150 (step S330), and the application within the 
server 1 50 creates an XML page 500 in response to the 
HTTP request (step S340). Specifically, the initial HTTP 
request instructs the application server 1 50 to execute 
the Active Server Pages ("ASP") script "default. asp" to 
generate the XML page 500 that contains the SMS mes- 
sage that needs to be send back to the mobile terminal 
1 1 0 having the ID equaling "111111". The following is an 
example of the XML page 500: 

<?xmi version="1.0"?> 
<SMS> 

1. News<BR/> 

2. Weather<BR/> 

3. Stocks<BR/> 

4. Jokes<BR/> 

<OPTION ONKEY^r ONPlCK=http://www.mo- 
bileinfo.com/news.asp> 

<OPTION ONKEY="2" ON PICK- http://www.mo- 
bileinfo.com/weather.asp> 

<OPTION ONKEY= M 3" ONPICK=http://www.mo- 
bileinfo.com/stocks. asp> 

<OPTlON ONKEY="4" ON PI CK*= http://www.mo- 
bileinfo.com/jokes.asp> 

<OPTIONI ONDEFAULT^http://www.mobileinfo. 
com/help. asp> 

<;sms> 

[0066] As shown above, the SMS message is part of 
the XML page 500 and is identified by the tag <SMS>. 
Also, the SMS message comprises a menu indicating 
that a "1" corresponds to a "News" menu option, a "2" 
corresponds to a "Weather" menu option, a "3" corre- 
sponds to a "Stocks" menu option, and a "4" corre- 
sponds to a "Jokes" menu option. Also, the OPTION 
tags indicate that ONKEY attributes indicate that the us- 
er of the mobile terminal 110 can respond to the SMS 
message with one of the following SMS messages: "1", 
"2", "3", or "4". Also, the ON PICK attributes indicate that 
the URI "http://www.mobileinfo.com/news.asp" corre- 
sponds to the SMS message "1", the URI *http://www. 
mobileinfo.com/weather.asp" corresponds to the SMS 



message "2", the URI °http://www. mobileinfo.com/ 
stocks. asp" corresponds to the SMS message "3", and 
the URI "http://www.mobileinfo.com/jokes.asp" corre- 
sponds to the SMS message "4". After the XML page 
5 500 is created, the application server 150 generates an 
initial HTTP response comprising the XML page 500 
and any necessary cookies and outputs the HTTP re- 
sponse to the CTW converter 140 (step S350). 
[0067] The CTW converter 1 40 receives the HTTP re- 
10 sponse via the HTTP request manager 1404 and con- 
verts the initial HTTP response into an initial SMS re- 
sponse (step S360). Specifically, the HTTP request 
manager 1 404 extracts any cookies from the HTTP re- 
sponse. Then, the manager 1404 supplies the cookies, 
15 the ID of the mobile terminal 110 (i.e. "11111 1"), and the 
URIs corresponding to the cookies to the cookies table 
1402, and the table 1402 stores the cookies such that 
they can be referenced based on the ID equaling 
"111111" and their respective URIs. In addition, the HT- 
20 TP manager 1404 extracts the ONKEY attributes, the 
ONPlCKattributes, and the ID of the mobile terminal 1 1 0 
and supplies such information to the session resolution 
table 1405, along with the SMS destination address of 
the application. Then, the table 1405 stores the informa- 
25 tion such that each of the ONPICK attributes (i.e. the 
URIs) is associated with its corresponding ONKEY at- 
tribute (i.e. the corresponding SMS message), and each 
of the ONKEY attributes Is associated with the ID of the 
mobile terminal 110 (i.e. "111111") and the SMS desti- 
ne nation address of the application (i.e. "999999"). Fig. 5 
is a generic example of the session resolution table 
1405, and Fig. 8 is a more detailed example of the table 
1405 and demonstrates how the Information is stored in 
the table 1 405. Also, as shown in Fig. 8, the SMS mes- 
35 sage "<default>" corresponds to any message that is 
sent from the mobile tenninal 110 and does not equal 
the SMS message "1", "2", "3 M , or "4-. 
[0068] In addition, the HTTP request manager 1404 
outputs the SMS message from the XML page 500 and 
40 the ID of the mobile terminal 1 1 0 to the SMS center con- 
nector 1403. Then, the connector 1403 forwards such 
information to the SMS center 130 (step S370), and the 
SMS center 130 forwards the information to the mobile 
terminal 110 (step S380). 
45 [0069] After the mobile terminal 1 1 0 receives the SMS 
message, it displays the SMS message on a display of 
the mobile terminal 110 as a menu 510 (step S390). 
When the user views the menu 510 on the display, he 
or she can select one of the options from the menu 510. 
so For example, in the illustrative, non-limiting embodi- 
ment, the user may select the "Weather" option from the 
menu by pressing a "2" button on the mobile terminal 
110. Furthermore, in another implementation, the user 
may press a different button or series of buttons to select 
55 the "Weather" option or may speak a certain word or 
words into the mobile terminal 1 1 0 and have the "Weath- 
er" option selected via voice recognition techniques. 
[0070] In any event, after the "Weather option is se- 
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lected, the mobile terminal 110 generates a second 
SMS message indicating that the "Weather" option was 
selected (e.g., generates a second SMS message con- 
taining a "2"). Then, the mobile terminal 110 sends the 
second SMS message, the ID of the mobile terminal 110 
(i.e. "111111"), and the SMS destination address or the 
application (i.e. "999999") to the SMS center 130 (step 
S400), and the SMS center 130 forwards such informa- 
tion to the CTW converter 140 (step S410). 
[0071] The CTW converter 140 inputs the second 
SMS message, the ID of the mobile terminal 110, and 
the SMS destination address via the SMS center con- 
nector 1 403 and converts the SMS message into a sec- 
ond HTTP request (step S420). Specifically, the connec- 
tor 1403 outputs the ID, the second SMS message, and 
the SMS destination address to the session resolution 
table 1 405. As shown in Fig. 8, the ID "111111", the SMS 
message containing a "2", and the SMS destination ad- 
dress "999999" correspond to the URI "http://www.mo- 
bileinfo.com/weather.asp\ As a result, the table 1405 
outputs the URI n http://www.mobileinfo.com/weather. 
asp" to the SMS center connector 1403, and the con- 
nector 1403 outputs the URI ,, http://www.mobileinlo. 
com/weather. asp", the SMS message "2", and the ID 
"1 11 1 1 1" to the HTTP request manager 1 404. Then, the 
HTTP request manager 1 404 generates the second HT- 
TP request in a manner that is similar to the manner in 
which the initial HTTP request was generated. An ex- 
ample of the second HTTP request is as follows: 

http://www.mobileinfo.com/weather.asp7mobile- 
num=1111H&text=2 

[0072] In the above example, the "URI portion" of the 
HTTP request equals "http://www.mobilelnfo.com/ 
weather.asp", the "ID portion" of the HTTP request 
equals ,, mobilenum~111111 H ! and the "SMS message 
portion" of the HTTP request equals "&text~2". As in the 
previous case, the HTTP request manager 1 404 sends 
the second HTTP request to the application server 1 50 
(step S430). In addition, the cookie that was stored in 
the cookies table 1402 after the initial HTTP response 
was received by the manager 1404 may also be output 
to the server 150. 

[0073] When the server 1 50 receives the second HT- 
TP request (with or without the stored cookie), the ap- 
plication within the server 150 generates an XML page 
520 (step S440). Specifically, the second HTTP request 
instructs the application server 150 to execute the ASP 
script "weather.asp" to generate the XML page 520 that 
contains the SMS message that needs to be send back 
to the mobile terminal 110 having the ID equaling 
"111111". The following is an example of the XML page 
520: 

<?xml version-" 1 .0"?> 
<SMS> 

Today's weather: Party cloudy, low 10 °C. high 15 
°C 

<OPTION ONDEFAULT=http://www.mobi!einfo. 



com/defau!t.asp> 
</SMS> 

[0074] After the XML page 520 is generated, the ap- 
5 plication server 150 generates a second HTTP re- 
sponse comprising the XML page 520 and any neces- 
sary cookies and outputs the HTTP response to the 
CTW converter 140 (step S450). Then, the CTW con- 
verter 140 converts the HTTP response into an SMS 
10 message in a manner that is similar to the manner de- 
scribed above (step S460), and the SMS message is 
output to the SMS center 130 {step S470). Afterwards, 
the SMS center 130 supplies the SMS message to the 
mobile terminal 110 (step S480), and the mobile termi- 
te nal 110 displays the message as weather information 
530 (step S490). 

[0075] In a preferred embodiment, the CTW converter 
140 utilizes a "read ahead" technique to enhance the 
speed at which the user can receive information via his 
20 or her mobile terminal 1 1 0. For example , in step S350, 
the CTW converter 140 receives the initial HTTP re- 
sponse containing the XML page 500 having the follow- 
ing ONPICK attributes: 

25 http://www.mobileinfo.com/news.asp 

http://www.mobileinfo.com/weather.asp 

http://www.mobileinfo.com/stocks.asp 

http://www.mobileinfo.com/jokes.asp 

30 While the CTW converter 140 is converting the initial 
HTTP response into an SMS message to send to the 
mobile terminal 110, the converter 140 may concurrently 
send four more HTTP requests to the application server 
1 50 requesting the server 1 50 to download the four XML 

35 pages relating to the four ONPICK attributes listed 
above. In one embodiment, the downloading of addition- 
al XML pages is performed if a specific attribute or pa- 
rameter (e.g., a "cache" attribute) is specified or set in 
the OPTION tag for the four ONPICK attributes. As a 

40 result, when the user subsequently selects the "Weath- 
er" option from the menu 51 0 and an SMS message con- 
taining a "2 M is output from the mobile terminal 110 to 
the CTW converter 140 (steps S400 and S41 0), the con- 
verter 1 40 has already received the HTTP responses 

45 containing the XML pages respectively relating to the 
news, weather, stocks, and jokes. Therefore, the CTW 
converter 140 can output the corresponding SMS mes- 
sage (i.e. the "Weather" SMS message) to the mobile 
terminal 1 1 0 very quickly, and thus, the mobile terminal 

so no displays the weather information 530 much faster 
in response to the user's selection of the "Weather 4 ' op- 
tion. 

[0076] As described above, the CTW converter 140 
quickly and easily converts the SMS or USSD protocols 
55 in an Internet protocol (e.g., the HTTP, XML : or HTML 
protocol) and vice versa. In addition, the Internet appli- 
cations stored on the server 150 can be easily designed 
or modified so that they can communicate with the mo- 
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bile terminals 110 via the CTW converter 140. Specifi- 
cally, as indicated above, an existing application can be 
modified so that it can communicate with the mobile ter- 
minal 1 1 0 by amending the XML pages of the application 
to add OPTION tags containing various ONPICK and 
ONKEY attributes and to add various SMS message 
texts identified by SMS lags. Also, new applications can 
be easily designed to communicate with the mobile ter- 
minal by creating the appropriate XML pages having the 
above information. Since XML pages can be easily cre- 
ated with existing Internet application software pro- 
grams and design tools, programmers can easily and 
quickly create Internet applications that can communi- 
cate with mobile terminals utilizing the SMS or USSD 
protocols. 

[0077] In light of the disclosure above, one skilled in 
the art will understand how to design and/or program 
the CTW converter 140 to convert proprietary protocols 
(e.g., the SMS and USSD protocols) into Internet proto- 
cols (e.g., the HTTP, XML ; and HTML protocols) and 
vice-versa. Also, in order to further illustrate an example 
of the conversion method of the present invention, the 
following technical description the Unstructured Supple- 
mentary Service Markup Language ("USSML") protocol 
is provided. The USSML protocol is an XML dialect that 
has been developed by Comverse, Ltd. to enable third 
party developers to easily implement the USSD protocol 
using Internet tools. The USSML protocol contains tags 
that can represent a menu-based application residing 
on the Internet, and a developer of the application can 
easily modify a WML or an HTML application so that it 
can communicate with a mobile terminal that communi- 
cates in accordance with an SMS or USSD protocol. 
[0078] The USSML protocol uses the <USSML> lag 
and the <OPTION> lag (as well as other tags). The 
<USSML> tag identifies all of the USSML settings and 
contents of the data transmitted in accordance with the 
USSML protocol and contains the "service" attribute. 
The "service" attribute identifies the general character- 
istic of a data message and can have one of the follow- 
ing values: 

* service^ "request" 

* service^notify" 

* service^ "sms" 

When the "service" attribute has the * service-'request" 
value (i.e. <USSML service=request>), the application 
sending the data message expects a response from a de- 
vice or application to which the data message is sent. An 
example of such a data message is the XML page 500 
shown in Fig. 7. When the "service" attribute has the * 
service^'notify" value (i.e. <USSMLservice= notify >), the 
application sending the data message does not expect a 
response from the device or application. An example of 
such a data message may be a "welcome" screen that is 
displayed when a device is initially turned on. When the 
"service" attribute has Ihe * service-"SMS" value (i.e. 



<USSML service--=SMS >), the data message contains an 
SMS message that is to be displayed on a mobile terminal 
110. An example of such a data message is the XML page 
520 shown in Fig. 7. 

5 [0079] The <OPTION> tag defines which SMS mes- 
sages may be received from a mobile terminal and 
which operations should be executed if one of the SMS 
messages is received. The <OPTION> tag contains an 
"acton" attribute, an "onptck" attribute, a "cache" at- 

w tribute, and a "default" attribute. 

[0080] The "acton" attribute specifies when the <OP 
TlON> tag should be activated. For example, if the "ac- 
ton" attribute equals "actonW", the <OPTION> tag 
containing such "acton" attribute will be executed if the 

15 mobile terminal outputs an SMS message containing a 
string that equals "I". Examples of the "acton" attribute 
are the ONKEY attributes discussed in conjunction with 
the above embodiments. 

[0081] The "onpick" attribute specifies which URi is 

20 called when the <OPTlON> tag is activated. For exam- 
ple, if the "acton" attribute equals "acton='1 u> and the 
"onpick" attribute contains the URI "http://domain.com? 
thissession=:1234" i the URI "http://domain.com? 
thissession-1234" will be called if the mobile terminal 

25 outputs an SMS message that equals "1". Examples of 
the "onpick" attribute are the ONPICK attributes dis- 
cussed in conjunction with the above embodiments. 
[0082] The "cache" attribute specifies whether or not 
the UR I identified in the "onpick" attribute should be read 

30 before a subsequent SMS message is received from the 
mobile terminal to activate the <OPTION> tag contain- 
ing the "onpick' attribute. For example, if the "cache" at- 
tribute has a predetermined value, the system will per- 
form the "read ahead" technique described above. For 

35 instance, assume that an initial SMS message output 
from the mobile terminal causes an application to output 
an HTTP response containing an XML page having the 
following "onpick" attributes (i.e. URIs): 

40 http://www.mobiieinfo.com/subject1 .asp 
http://www.mobileinfo.com/subject2.asp 
http://www.mobileinfo.com/subject3.asp 
http://www.mobileinfo.com/subject4.asp 

45 if the "cache" attribute has a predetermined value, the 
system will read all of the URIs listed above before the 
mobile terminal outputs a subsequent SMS message 
containing a string that equals the "acton" attribute as- 
sociated with one of the above "onpick" attributes. Thus, 

50 when the subsequent SMS message is received from 
the mobile terminal, the corresponding URI has already 
been called, and the response time of the system is dra- 
matically improved. 

[0083] The "default" attribute specifies an <OPTION> 
55 tag that is activated if an SMS message is received that 
does not contain a string that equals the "acton" attribute 
of any other <OPTlON> tag. 

[0084] An example of the use of the USSML protocol 
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will be described below. First, when a user activates his 
or her mobile terminal, a controller (e.g., the CTW con- 
verter 140) of the communication system activates a file 
"start, ussml", and such file automatically generates an 
HTTP request that calls the following URl; 

hltp://operaior. com/main. cgi?mobilenum= 

0788991 1 22&answerstring^" ,, &waitsecond s-2 
Upon receiving the HTTP request, the relevant applica- 
tion generates an HTTP response that contains the fol- 
lowing XML page: 

<?xml version="1.0"?> 

<USSML service^- notify> 

Welcome to Super Menu <BR/> 

Sponsored by Comverse Tech <BR/> 

<OPTION defaults " ONPlCK=-http://operator. 

com/main. cgi?waitseconds=2/> 

</USSML> 

<?xml version="1 ,0"?> 
<USSML service=request> 
Hello Mr. Tom Arnold <BR/> 
Please enter your choice <BR/> 
<OPTION onpick^'httpV/operator.com/sport" ac- 
ton-" r> 

1. Sports Result -OPTION> 

<OPTION onpick= M http://operator.com/stock ,, ac- 
ton="2"> 

2. Stocks </OPTION> 

<OPTION onpick="http ://operator. com/weather 
acton="3"> 

3. Today's Weather <OPTION> 

<OPTlON onpick="http:operator.com/def de- 
faults" 1"> 
</OPTION> 
</USSML> 

[0085] In response to the HTTP response, the con- 
troller causes the following message to be displayed on 
the display of the mobile terminal for two seconds: 

Welcome to Super Menu 
Sponsored by Comverse Tech. 

Then, after two seconds pass, the following message is 
displayed on the mobile terminal: 

Hello Mr. Tom Arnold 
Please enter your choice 

1 . Sports 

2. Stocks 

3. Today's Weather 

If the user instructs the mobile terminal to output an SMS 
message containing the string "2", the tag <OPTIOM on- 
pick^"http://operator.com/stock c ' acton=t"2"> instructs 
the controller to generate an HTTP request that calls the 
following URl: 



"http://operator.com/siock M 
In response to the HTTP request, the relevant applica- 
tion will generate an HTTP response containing the fol- 
lowing XML page: 

5 

<?xml version="1.0"?> 
<USSML service-request> 
Please enter your stock's symbol <BR/> 
<OPTION onpick="http ://ope rator.com/quote" de- 
10 faull«"1"> 
</OPTlON> 
<AJSSML> 

As a result, the controller outputs an SMS message to 
*5 the mobile terminal that causes the mobile terminal to 
display the following message: 

Please enter your stock's symbol 
If the user instructs the mobile terminal to outputs an 
SMS message containing a stock "ticker symbol" for a 
20 company (e.g. , the ticker symbol "CMVT") , the tag <OP- 
TION onpick="http ://operator.com/quote M default="1"> 
instructs the controller to generate an HTTP req uest that 
calls the following URl. 

http://operator.com/quote7mobile- 
25 num=0788991122&answerstring=CMVT 

In response to the HTTP request, the relevant applica- 
tion will generate an HTTP response containing the fol- 
lowing XML page: 

30 <?xml version="1 .0"?> 
<USSML service=sms> 
CMVT: 1234$<BR/> 
Cnange: +235% 
</USSML> 

35 

As a result, the controller outputs an SMS message to 
the mobile terminal that causes the mobile terminal to 
display the following message: 

40 CMVT:$1234 

Change: +235% 

[0086] As described in the embodiments above, a mo- 
bile terminal 110 outputs mobile terminal messages (e. 

45 g. ( SMS or USSD) that are automatically translated into 
Internet requests (e.g., HTTP requests), and the Inter- 
net requests can access an Internet application running 
on a regular web server 1 55 or 1 75. Then, the web serv- 
er 155 or 1 75 generates internet responses (e.g., HTTP 

50 responses) based on the internet requests, and the re- 
sponses are translated back into mobile terminal mes- 
sages. As a result, the present invention enables the us- 
er of the mobile terminal 11 0 T which uses an SMS or 
USSD protocol to access various Internet applications, 

55 which can be easily created or adapted to communicate 
with mobile terminal 110. 

[0087] For example, the present invention enables an 
application developer to simply and easily create an ap- 
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plication in a web server 155 or 175 that can be ac- 
cessed by SMS or USSD terminals, without requiring 
the developer to spend the substantial resources need- 
ed to specifically design the application to interact with 
SMS or USSD terminals. In other words, applications 
can be accessed by SMS or USSD mobile terminals 
without having to specifically design or implement the 
applications via the complex SMS or USSD protocols. 
[0086] In addition., the CTW converter 140 described 
above is clearly not limited to translating SMS or USSD 
protocols into an HTTP protocol and vice versa. For ex- 
ample, the converter 140 may translate SMPP, UCP, 
CIMD, or NIP protocols to the HTTP protocol and vice 
versa. Also, the converter may translate other telephone 
protocols to other Internet protocols and vice versa. 
[0089] Also, the messages sent from and received by 
the mobile terminal 1 1 0 may be transferred over various 
cellular systems now in use. For example, the messag- 
es may be transferred over the GSM, Advanced Mobile 
Phone Service ("AMPS"), iS-54, IS-95, or IS-136 sys- 
tem. Messages may also be transferred over future sys- 
tems, based on the 2.5G or 3G standards. The 2.5G 
standard, in all its variations (e.g., the General Packet 
Radio Service ("GPRS") or EDGE variation), is currently 
being implemented in world markets. Also, the 3G 
standard will be implemented in Japan later this year, in 
Europe in the year 2001 , and in the United States in the 
year 2002. Th us, a preferred embodiment of the present 
invention will be able to operate in accordance with all 
the standards mentioned above. In addition, the various 
cellular systems over which the invention will operate 
may use all the various modulation schemes, such as 
Frequency Division Mutiple Access ("FDMA"). TDM A, 
CDMA, or any combination thereof, to transmit the mes- 
sages. Furthermore, the present invention may support 
various devices and services that operate in a half-du- 
plex mode and devices that operation in a full-duplex 
mode in any of its variations (e.g., a Frequency Division 
Duplex fFDD") variation, a Time Division Duplex 
("TDD") variation, a Code Division Duplex ("CDD") var- 
iation) or any combination of such variations. 
[0090] In addition, as described above, the CTW con- 
verter 1 40 can support normal web server "sessions" by 
accepting "cookies" from a web server 155 or 175 and 
storing them in accordance with an ID (e.g.. a mobile 
telephone number) of the mobile telephone 11 0 access- 
ing the server 155 or 175. Thus, the next request from 
the same mobile telephone 110 will access the web 
server 155 or 175 with an HTTP request that provides 
the server 1 55 or 1 75 with the stored cookie. As a result, 
the application running on the server 155 or 1 75 imme- 
diately resumes executing in the context of the session 
with the specific mobile terminal 110 that sent the pre- 
vious HTTP request. Consequently, the mobile terminal 
110 can communicate with the web server 155 or 1 75 
in the exact same manner as a desktop browser com- 
municates with the web server 155 or 1 75. 
[0091] The previous description of the preferred em- 



bodiments is provided to enable a person skilled in the 
art to make or use the present invention. Moreover, var- 
ious modifications to these embodiments will be readily 
apparent to those skilled in the art, and the generic prin- 

5 cipies defined herein may be applied to other embodi- 
ments without the use of inventive faculty. Therefore, the 
present invention is not intended to be limited to the em- 
bodiments described herein but is to be accorded the 
widest scope as defined by the claims and equivalents 

10 thereof. 



Claims 

15 1. A communication system, comprising: 

a protocol converting controller that receives 
a first upstream mobile terminal message having a 
mobile terminal communication protocol and con- 
verts the first upstream mobile terminal message in- 

20 to a first upstream Internet message having an In- 
ternet protocol. 

2. The communication system as claimed in claim 1, 
wherein the protocol converting controller receives 

25 a first downstream Internet message having the In- 
ternet protocol and converting the first downstream 
Internet message into a first downstream mobile 
terminal message having the mobile terminal com- 
munication protocol, 

30 wherein the first downstream Internet mes- 

sage is responsive to the first upstream Internet 
message. 

3. The system as claimed in claim 1 or claim 2, where- 
35 in the protocol converting controller receives the 

first upstream mobile terminal message, selects a 
first upstream Internet address corresponding to 
the first upstream mobile terminal message, and 
generates the first upstream Internet message 
40 based on the first upstream Internet address, 

wherein the first upstream Internet message 
is supplied to an Internet application. 

4. The communication system as claimed in claim 3, 
^5 wherein the protocol converting controller deter- 
mines if the first upstream mobile terminal message 
is part of an existing session with the Internet appli- 
cation, 

50 wherein, when the first upstream mobile termi- 

nal message is pan of the existing session, the 
protocol converting controller selects a first se- 
lected Internet address as the first upstream In- 
ternet address, and 

55 wherein, when the first upstream mobile termi- 

nal message is not part of the existing session, 
the protocol converting controller selects a sec- 
ond selectee Internet address as the first up- 
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stream Internet address. 

5. The communication system as claimed in claim 4, 
wherein a first downstream Internet message com- 
prises the first selected Internet address, first down- 
stream data corresponding to a first downstream 
mobile terminal message, and a first responsive 
mobile terminal message that is associated with the 
first selected Internet address. 

wherein the first downstream Internet message 
is supplied to the protocol converter controller 
and the protocol converter controller generates 
the first downstream mobile terminal message 
based on the first downstream data, 
wherein the first upstream mobile terminal mes- 
sage is supplied to the protocol converting con- 
troller in response to the first downstream mo- 
bile terminal message, and 
wherein the protocol converter controller deter- 
mines that the first upstream mobile terminal 
message is part of the existing session with the 
internet application when the first upstream 
mobile terminal message corresponds to the 
first responsive mobile terminal message. 

6. The communication system as claimed in claim 5, 
wherein the first downstream Internet message fur- 
ther comprises a first downstream identification cor- 
responding to a destination of the first downstream 
mobile terminal message and a first downstream 
destination address of the Internet application, 

wherein the protocol converter controller re- 
ceives the first upstream mobile terminal mes- 
sage, a first upstream identification corre- 
sponding to a source of the first upstream mo- 
bile terminal message, and a first upstream 
destination address corresponding to the first 
upstream mobile terminal message, and 
wherein the protocol converter controller deter- 
mines that the first upstream mobile terminal 
message is part of the existing session with the 
Internet application when the first upstream 
mobile terminal message corresponds to the 
first responsive mobile terminal message, the 
first upstream identification corresponds to the 
first downstream identification, and the first up- 
stream destination address corresponds to the 
first downstream destination address. 

7. The communication system as claimed in claim 6, 
wherein, when the protocol converter controller de- 
termines that the first upstream mobile terminal 
message is not part of the existing session with the 
Internet application, the protocol converter control- 
ler selects the second selected Internet address 
based on the first upstream destination address. 



8. The communication system as claimed in claim 5, 
wherein, if the first downstream Internet message 
further comprises a cache parameter, the protocol 
converter controller generates a second upstream 
5 Internet message based on the first selected Inter- 
net address before the protocol converter controller 
receives the first upstream mobile terminal mes- 
sage, 

10 wherein the protocol converter controller re- 

ceives a second downstream Internet message 
corresponding to the second upstream Internet 
message, 

wherein the second downstream Internet mes- 
*5 sage comprises second downstream data cor- 

responding to a second downstream mobile 
terminal message, 

wherein, when the protocol converter controller 
receives the first upstream mobile terminal 

20 message, the protocol converter controller de- 

termines if the second downstream mobile ter- 
minal message is responsive to the first up- 
stream mobile terminal message, and 
wherein, when the second downstream mobile 

25 terminal message is responsive to the first up- 

stream mobile terminal message., the protocol 
converter controller outputs the second down- 
stream mobile terminal message. 

30 9. The system according to any of claims 1 to 8, 
wherein the protocol converting controller receives 
a first downstream Internet message from an Inter- 
net application before receiving the first upstream 
mobile terminal message, 

35 

wherein the first downstream Internet message 
comprises a first downstream cookie, 
wherein the protocol converting controller de- 
termines if the Internet application requires the 
first downstream cookie to appropriately proc- 
ess the first upstream Internet message, 
wherein, when the first downstream cookie is 
required to appropriately process the first up- 
stream Internet message , the protocol convert - 
45 ing controller outputs the first downstream 

cookie as a first upstream cookie, along with 
the first upstream Internet message. 

10. The communication system as claimed in claim 9, 
so wherein first downstream Internet address further 
comprises a first downstream identification and a 
first selected internet address, and 

wherein the protocol converting controller de- 
termines that the Internet application requires the 
55 first downstream cookie to appropriately process 
the first upstream Internet message if the first up- 
stream identification and the first upstream Internet 
address respectively correspond to the first down- 
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stream identification and the first selected Internet 
address. 

11. A communication system, comprising: 

a protocol converting controller that receives 
a first downstream Internet message having an In- 
ternet protocol and converts the first downstream 
Internet message into a first downstream mobile 
terminal message having a mobile terminal commu- 
nication protocol, 

wherein the first downstream Internet message 
comprises an Internet data page having: 

first downstream mobile terminal message 
data that is used to generate the first down- 
stream mobile terminal message: 
first responsive mobile terminal message 
data corresponding to a first responsive 
upstream mobile terminal message that re- 
sponds to the first downstream mobile ter- 
minal message; and 

a first responsive Internet address that cor- 
responds to the first responsive upstream 
mobile terminal message : 

wherein the protocol converting controller gen- 
erates the first downstream mobile terminal 
message based on the first downstream mobile 
terminal message data and outputs the first 
downstream mobile terminal message. 

12. The communication system as claimed in claim 11 , 
wherein the protocol converting controller receives 
a first upstream mobile terminal message having 
the mobile terminal communication protocol and 
determines if the first upstream mobile terminal 
message corresponds to the first responsive up- 
stream mobile terminal message, 

wherein, when the first upstream mobile termi- 
nal message corresponds to the first respon- 
sive upstream mobile terminal message, the 
protocol converting controller generates a first 
upstream Internet message having the Internet 
protocol, and 

wherein the first upstream Internet message 
comprises the first responsive Internet ad- 
dress. 

13. The communication system as claimed in claim 12, 
wherein the protocol converting controller receives 
the first downstream Internet message from an In- 
ternet application, 

wherein the first downstream Internet message 
further comprises a first downstream cookie, 
wherein the protocol converting controller de- 



termines if the Internet application requires the 
first downstream cookie to appropriately proc- 
ess the first upstream Internet message, 
wherein, when the first downstream cookie is 
5 required to appropriately process the first up- 

stream Internet message, the protocol convert- 
ing controller outputs the first downstream 
cookie as a first upstream cookie, along with 
the first upstream internet message. 

10 

14. A communication system, comprising: 

an Internet server that receives a first up- 
stream Internet message having an Internet proto- 
col, wherein the first upstream Internet message is 
15 based on a first upstream mobile tenninal message 
having an mobile terminal communication protocol, 

wherein the Internet server contains an Internet 
application that generates a first downstream 
20 Internet message based on the first upstream 

Internet message, 

wherein the first downstream Internet message 
comprises an Internet data page having: 

25 first downstream mobile terminal message 

data that is used to generate a first down- 
stream mobile terminal message that re- 
sponse to the first upstream mobile termi- 
nal data; 

30 first responsive mobile terminal message 

data corresponding to a first responsive 
upstream mobile terminal message that re- 
sponds to the first downstream mobile ter- 
minal message; and 

35 a first responsive Internet address that cor- 

responds to the first responsive upstream 
mobile terminal message. 

15. The communication system as claimed in claim 14, 
40 wherein the first downstream Internet message fur- 
ther comprises a first downstream cookie that is re- 
quired for a second upstream Internet message to 
be appropriately processed by the Internet applica- 
tion and 

45 wherein the second upstream Internet mes- 

sage corresponds to the first responsive upstream 
mobile terminal message. 

16. A system according to any of the preceding claims, 
so wherein the mobile terminal communication proto- 
col is one of an SMS protocol and a USSD protocol. 

17. A system according to any of the preceding claims, 
wherein the Internet protocol is one of an HTTP pro- 

55 toco I and an XML protocol. 

18. A communication method, comprising: 
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(a) receiving a first upstream mobile terminal 
message having a mobile terminal communica- 
tion protocol; and 

(b) converting the first upstream mobile termi- 
nal message into a first upstream Internet mes- 
sage having an Internet protocol. 

19. The method as claimed in claim 1 8, further compris- 
ing: 

(c) receiving a first downstream Internet mes- 
sage having the Internet protocol and converting 
the first downstream Internet message into a first 
downstream mobile terminal message having the 
mobile terminal communication protocol, 

wherein the first downstream Internet mes- 
sage is responsive to the first upstream Internet 
message. 

20. The method as claimed in claim 18 or claim 19, 
wherein the mobile terminal communication proto- 
col is one of an SMS protocol and a USSD protocol. 

21. The method as claimed in any one of claims 18 to 
20\ wherein the Internet protocol is one of an HTTP 
protocol and an XML protocol. 

22. The method as claimed in any one of claims 18 to 
21, wherein the step (b) comprises: 

(b1 ) selecting a first upstream Internet address 
corresponding to the first upstream mobile ter- 
minal message; and 

(b2) generating the first upstream Internet mes- 
sage based on the first upstream Internet ad- 
dress, 

wherein the first upstream Internet message 
is supplied to an Internet application. 

23. The method as claimed in claim 22, wherein the 
step (bl) comprises: 

(b1a) determining if the first upstream mobile 
terminal message is part of an existing session 
with the Internet application; 
(bib) when the first upstream mobile terminal 
message is part of the existing session, select- 
ing a first selected Internet address as the first 
upstream Internet address; and 
(b1c) when the first upstream mobile terminal 
message is not part of the existing session, se- 
lecting a second selected Internet address as 
the first upstream Internet address. 

24. The method as claimed in claim 23, further compris- 
ing: 

(c) receiving a first downstream Internet mes- 



sage comprising the first selected Internet ad- 
dress, first downstream data corresponding to 
a first downstream mobile terminal message, 
and a first responsive mobile terminal message 
5 that is associated with the first selected Internet 

address; 

(d) generating the first downstream mobile ter- 
minal message based on the first downstream 
data; and 

'0 (e) generating the first upstream mobile termi- 

nal message in response to the first down 
stream mobile terminal message, and 

wherein the step (b1a) comprises: 
'5 (bial) determining that the first up- 

stream mobile terminal message is part of the ex- 
isting session with the Internet application when the 
first upstream mobile terminal message corre- 
sponds to the first responsive mobile terminal mes- 
20 sage. 

25. The method as claimed in claim 24, wherein the first 
downstream internet message further comprises a 
first downstream identification corresponding to a 

25 destination of the first downstream mobile terminal 
message and a first downstream destination ad- 
dress of the Internet application, wherein the step 
(a) comprises: 

30 (al) receiving a first upstream identification cor- 

. responding to a source of the first upstream mo- 
bile terminal message and a first upstream des- 
tination address corresponding to the first up- 
stream mobile terminal message, and 
35 wherein the step (bi a1 ) comprises: 

(b1 a1 a) determining that the first upstream mo- 
bile terminal message is part of the existing 
session with the Internet application when the 
first upstream mobile terminal message corre- 
4 0 spends to the first responsive mobile terminal 

message, the first upstream identification cor- 
responds to the first downstream identification, 
and the first upstream destination address cor- 
responds to the first downstream destination 
45 address. 

26. The method as claimed in claim 25, wherein step 
(b1c) comprises: 

(bid) when the first upstream mobile terminal 
50 message is not part of the existing session with the 
Internet application,, selecting the second selected 
Internet address based on the first upstream desti- 
nation address. 

55 27. The method as claimed in any of claims 24 to 26, 
further comprising: 

(f) determining if the first downstream Internet 
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message f urthercomprises a cache parameter; 

(g) when the first downstream Internet mes- 
sage comprises the cache parameter, generat- 
ing a second upstream Internet message 
based on the first selected Internet address be- 
fore receiving the first upstream mobile terminal 
message; 

(h) receiving a second downstream Internet 
message corresponding to the second up- 
stream Internet message, wherein the second 
downstream Internet message comprises sec- 
ond downstream data corresponding to a sec- 
ond downstream mobile terminal message; 

(i) when the first upstream mobile terminal mes- 
sage is received ( determining if the second 
downstream mobile terminal message is re- 
sponsive to the first upstream mobile terminal 
message; and 

(j) when the second downstream mobile termi- 
nal message is responsive to the first upstream 
mobile terminal message, outputting the sec- 
ond downstream mobile terminal message. 

28. The method as claimed in claim 18, further compris- 
ing: 

(c) receiving a first downstream Internet mes- 
sage from an Internet application before receiv- 
ing the first upstream mobile terminal message, 
wherein the first downstream Internet message 
comprises a first downstream cookie; 

(d) determining if the Internet application re- 
quires the first downstream cookie to appropri- 
ately process the first upstream Internet mes- 
sage; and 

(e) when the first downstream cookie is re- 
quired to appropriately process the first up- 
stream Internet message, outputting the first 
downstream cookie as a first upstream cookie, 
along with the first upstream Internet message. 

29. The method as claimed in claim 28, wherein a first 
downstream Internet address further comprises a 
first downstream identification and a first selected 
internet address, and 

wherein the step (d) comprises: 
(d1) determining that the Internet application 
requires the first downstream cookie to appropriate- 
ly process the first upstream Internet message if the 
first upstream identification and the first upstream 
Internet address respectively correspond to the first 
downstream identification and the first selected in- 
ternet address. 

30. A software program contained in a computer read- 
able medium, 

wherein the software program instructs a commu- 
nication system to perform a routine, comprising: 



34 

(a) receiving a first upstream Internet message 
having an Internet protocol, wherein the first 
upstream Internet message is based on a first 
upstream mobile terminal message having an 

5 mobile terminal communication protocol , 

(b) generating a first downstream Internet mes- 
sage based on the first upstream Internet mes- 
sage, wherein the first downstream Internet 
message comprises an Internet data page hav- 

10 ing: 

first downstream mobile terminal message 
data that is used to generate a first down- 
stream mobile terminal message that re- 
15 sponse to the first upstream mobile termi- 

nal data; 

first responsive mobile terminal message 
data corresponding to a first responsive 
upstream mobile terminal message that re- 
20 sponds to the first downstream mobile ter- 

minal message; and 

a first responsive Internet address that cor- 
responds to the first responsive upstream 
mobile terminal message. 

25 

31. The software program as claimed in claim 30, 
wherein the mobile terminal communication proto- 
col is one of an SMS protocol and a USSD protocol. 

30 32. The software program as claimed in claim 30 or 
claim 31, wherein the Internet protocol is an HTTP 
protocol and an XML protocol. 

33. The software program as claimed in any of claims 
35 30 to 32, wherein the first downstream Internet mes- 
sage further comprises a first downstream cookie 
that is required tor a second upstream Internet mes- 
sage to be appropriately processed, and 

wherein the second upstream Internet mes- 
40 sage corresponds to the first responsive upstream 
mobile terminal message. 
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(54) Web development and deployment using SMS and USSD 



(57) A communication system is provided that con- 
tains a protocol converting controller. The controller re- 
ceives an upstream mobile terminal (110) message from 
a mobile terminal and converts the upstream mobile ter- 
minal message into an upstream Internet message to 
be used by an Internet server. Also, the controller re- 
ceives a downstream Internet message from the Inter- 
net server and converts the downstream Internet mes- 
sage into a downstream mobile terminal message to be 
used by the mobile terminal. The upstream and down- 
stream mobile terminal messages may have an SMS or 
USSD protocol, and the upstream and downstream In- 
ternet messages may have an HTML, HTTP, or XML 
protocol. In one implementation, the downstream Inter- 
net message is output by an Internet application stored 
on the Internet server and contains an Internet page (e, 
g. an XML page) having mobile terminal data for creat- 
ing the downstream mobile terminal message. Also, the 
XML page contains potentially responsive mobile termi- 
nal messages and Internet addresses that respectively 
correspond to the potentially responsive mobile terminal 



messages. As a result, when the protocol converting 
controller receives an upstream mobile terminal mes- 
sage, it can determine if such message is part of an ex- 
isting session with the Internet application by determin- 
ing if the upstream mobile terminal message corre- 
sponds to any of the potentially responsive mobile ter- 
minal messages. If the upstream mobile terminal mes- 
sage corresponds to one of the messages, it is part of 
the existing session, and the upstream Internet mes- 
sage is generated based on the Internet address that is 
associated with the potentially responsive mobile termi- 
nal message corresponding to the upstream mobile ter- 
minal message. Furthermore, the Internet application 
may output cookies to the protocol converting controller 
that are used to enhance the communications between 
a mobile terminal and the Internet application. In addi- 
tion, a method performed by the communication system 
and a software program for controlling the communica- 
tion system are provided. 
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